我在 Sekoya Tech 做 LibreDB Studio，一個 MIT 授權、自己架在伺服器上、用瀏覽器開的資料庫用戶端。這篇不是產品介紹，是把我們做這個東西的過程、選擇跟踩到的坑寫下來，特別是「相容」這兩個字帶來的麻煩。

為什麼不做桌面軟體

一開始的需求很單純：資料庫在內網或雲上，開發者的機器在外面。桌面用戶端的做法是每個人在自己電腦上裝一份，然後每個人各自維護一份連線設定、各自存一份憑證、各自開一條通道進去。

我們把它反過來：程式跑在資料庫旁邊，人只要開瀏覽器。憑證留在伺服器上，不落到每個人的筆電裡；升級只升一份；要收回誰的存取權，改伺服器上的設定就好。

代價也很實在。瀏覽器不能直接講資料庫的傳輸協定，所以後端必須自己實作連線、查詢、串流結果這一整條路，而且大結果集不能一次塞給前端。這是整個專案最大的一筆工程成本，決定做的時候就知道了。

16 個驅動，然後是 26 個「宣稱相容」的引擎

我們自己寫的驅動有 16 個。真正麻煩的是另外那 26 個宣稱跟某個主流引擎 wire protocol 相容的資料庫。

「相容」在實務上大概是這樣：連線握手通常沒問題，跑一般的查詢也沒問題，然後你去問它「這個資料庫裡有哪些表、欄位型別是什麼、索引長什麼樣」，回來的東西就開始不一樣了。系統目錄的欄位少一兩個、型別代碼對不上、有些語句直接不支援。用戶端偏偏最依賴這些中繼資料，因為左邊那棵樹就是靠它畫出來的。

第二個坑是版本字串。很多相容型引擎會回報一個它模仿的對象的版本號，你如果照著版本號決定要走哪條程式路徑，就會在某些引擎上走錯。

所以我們的做法是不信版本字串，改成開連線之後實際去試：這個引擎支不支援某個中繼資料查詢、某個語法、某種型別，試出來的結果才拿來決定介面上顯示什麼。程式碼比較醜，但這是唯一穩的做法。

打包

發行方式是 Docker 映像。這件事的好處在支援上：使用者回報問題的時候，我們知道他跑的是哪個版本、什麼環境，不用先花三輪訊息確認他的 Python 或 Node 版本。

過程中比較實際的一課是，各家自架平台的應用商店（各種 NAS、容器管理面板）幾乎都有自己的一套範本格式跟審核流程，而且各自不同。我們一個一個送，每一個都要讀它的規範文件。這部分的工作量比想像中大很多，但它是使用者真的會用到的安裝路徑。

我們測了 LLM 驅動的資料庫 agent，然後把失敗案例也公開

最近做的一件事是量測本地語言模型在資料庫任務上到底能做到什麼程度：六種任務、八百四十次執行。

結論不是「很好用」也不是「不能用」，而是分得很開——有些任務的成功率高到可以放進工具裡，有些任務失敗得很難看，而且失敗的方式常常是「產生了一個語法正確、看起來合理、但答錯的查詢」。這種失敗最危險，因為它不會報錯。

我們把完整結果包含失敗案例都放出來了，沒有只挑漂亮的數字。

現在的狀態

程式是 MIT 授權，原始碼在 GitHub 上：libredb/libredb-studio

如果你也在做相容性這一塊，特別是被某個宣稱相容的引擎坑過，我很想聽你踩到的是什麼。中繼資料那一層我們到現在還在補。